home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000394_rock_spambust_violin@yahoo.com_Sun Aug 20 15:41:54 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: reader2.panix.com!reader1.panix.com!panix!newsfeed.media.kyoto-u.ac.jp!newsfeed.icl.net!newspump.monmouth.com!newspeer.monmouth.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!74g2000cwt.googlegroups.com!not-for-mail
  2. From: "tomviolin" <rock_spambust_violin@yahoo.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: extremely high latency channel
  5. Date: 10 Aug 2006 12:55:57 -0700
  6. Organization: http://groups.google.com
  7. Lines: 39
  8. Message-ID: <1155239757.815134.180170@74g2000cwt.googlegroups.com>
  9. NNTP-Posting-Host: 129.89.149.197
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset="iso-8859-1"
  12. X-Trace: posting.google.com 1155239763 23345 127.0.0.1 (10 Aug 2006 19:56:03 GMT)
  13. X-Complaints-To: groups-abuse@google.com
  14. NNTP-Posting-Date: Thu, 10 Aug 2006 19:56:03 +0000 (UTC)
  15. User-Agent: G2/0.2
  16. X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6,gzip(gfe),gzip(gfe)
  17. Complaints-To: groups-abuse@google.com
  18. Injection-Info: 74g2000cwt.googlegroups.com; posting-host=129.89.149.197;
  19.    posting-account=ornCOQwAAAAyCG4a7NOAj_SMr54FiqNu
  20. Xref: panix comp.protocols.kermit.misc:15525
  21.  
  22. I am communicating with a remote system (a buoy) using MaxStream 900MHz
  23. radios.  Due to various circumstances, the latency on the line is very
  24. high, up to 30 seconds sometimes.   Often I'll press return at the unix
  25. or Kermit prompt several times, and 20-30 seconds later the several
  26. prompts will appear.  Same thing with echoes of typing.
  27.  
  28. However, due to the error checking of the radios, the line is rather
  29. reliable.  Occasionally some data gets lost, but most of the time it
  30. all gets through.
  31.  
  32. Also, if you try to send something while the other side is trying to
  33. send, it causes extra delays, and that is where data is lost most of
  34. the time.
  35.  
  36. Our major problem is trying to tweak the Kermit protocol to deal with
  37. this.  Ultimately, if the system could send a packet, PATIENTLY wait
  38. for an  acknowledgement without trying to send anything (and only after
  39. a minute or so attempt a retry), it would probably work OK.
  40.  
  41. As it is, we get extremely dismal throughput, even on ROBUST setting,
  42. because it seems I can't get Kermit to wait patiently enough for a
  43. response.  I've tried to set the send and receive timeouts to high
  44. values (like 60) but I keep seeing messages about timeouts of 15
  45. seconds or less during the transfer attempts.
  46.  
  47. We've gotten much better results simply using "cat" to display the
  48. files and using session logging to capture the text.  But I should
  49. think that a protocol as versatile as Kermit could do better than
  50. "cat".  I've even tossed around the idea of tacking checksums to the
  51. end of the files and doing my own error checking in script.  But that
  52. seems so silly because the Kermit protocol should be able to handle
  53. this.
  54.  
  55. Does anyone have any hints here?  What's particularly frustrating is
  56. that the interactive command prompt experience over this link isn't all
  57. that bad, it just usually takes a few seconds for things to echo.
  58.  
  59. Thanks for any tips.
  60.